<!DOCTYPE html>
<html lang="en" >
<head>
    <title>Atomsk - GIN format - Pierre Hirel</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="stylesheet" media="screen" type="text/css" title="Default" href="./default.css" />
    <link rel="icon" href="../img/atomsk_logo.png" type="image/png" />
</head>
   
<body>

<p><a href="./index.html">Back to main menu</a></p>

<h2>Format: GIN</h2>

<p><strong>Name:</strong> <a href="https://nanochemistry.curtin.edu.au/gulp/">General Utility Lattice Package (GULP)</a> input file</p>

<p><strong>Extension:</strong> gin, grs or res</p>

<p><strong>Specification:</strong> <a href="https://nanochemistry.curtin.edu.au/gulp/help/manuals.cfm">GULP documentation</a></p>

<p><strong>Visualization programs:</strong> <a href="http://gdis.sourceforge.net/">gdis</a></p>


<h4>Restrictions</h4>

<p>When reading GULP input files (gin, res or grs), Atomsk will always read the positions of atom cores. The "atom names" in the first column should always start with the species symbol (one or two letters) for Atomsk to recognize it. It may be appened by any string or characters (e.g. O1, Ti_2, etc.). If velocities are present, they are saved as auxiliary properties.</p>

<p>If <strong>electronic shells</strong> are present (in the sense of an ionic core-shell model potential) their positions are also read, but beware that they will be transferred for output only to formats that support it (like GULP files themselves, or <a href="./format_dlp.html">DL_POLY CONFIG files</a>). For Atomsk to associate cores and shells correctly, the position of each shell should always appear right after the position of the corresponding core (like in the example below), or all core positions should be contiguous and followed by all shells positions in a matching order. If it is not the case (i.e. if cores and shells are written in any other arbitrary order) one can use the <a href="./option_bindshells.html">option <code>-bind-shells</code></a>.</p>

<p>If the <strong>electric charges</strong> of cores (and shells) are defined in the section "species" then Atomsk will store them as auxiliary properties. If the charges appear after each particle coordinate, then they will override the ones defined in the "species" section.</p>

<p>The reading of GULP files come essentially with two restrictions. First, symmetry operations are not taken into account. So, if coordinates of a primitive lattice are used, only atoms in that primitive cell will be read and output. Symmetry is a whole other story to implement, so it was not done in this program. And second, since NEB was implemented in GULP (&#62;3.4) the restart files (res or grs) can contain all atomic positions for all images of NEB. This is not recognized here, and only the positions of the 1st NEB image will be read and converted by Atomsk.</p>

<p>Atomsk can only write a basic GIN file, containing the cell parameters and the positions of the cores (and shells if any) with the following format:</p>

<div class="txtfile"><h5>example.gin</h5>
<p><code>opti<br/>
         title <br/>
         &#60;comment&#62; <br/>
         end <br/>
         <br/>
         vectors <br/>
         &#60;H(1,1)&#62; &#60;H(1,2)&#62; &#60;H(1,3)&#62; <br/>
         &#60;H(2,1)&#62; &#60;H(2,2)&#62; &#60;H(2,3)&#62; <br/>
         &#60;H(3,1)&#62; &#60;H(3,2)&#62; &#60;H(3,3)&#62; <br/>
         [1 1 1 1 1 1]<br/>
         <br/>
         cartesian<br/>
         &#60;atom1&#62; core &#60;x1&#62; &#60;y1&#62; &#60;z1&#62; [q1&nbsp;  [occ1 [0.0]]] [fixx1 fixy1 fixz1]<br/>
         &#60;atom1&#62; shel &#60;x1&#62; &#60;y1&#62; &#60;z1&#62; [qs1 [occ1 [rad1]]] [1 1 1]<br/>
         &#60;atom2&#62; core &#60;x2&#62; &#60;y2&#62; &#60;z2&#62; [q2&nbsp;  [occ2 [0.0]]] [fixx2 fixy2 fixz2]<br/>
         &#60;atom2&#62; shel &#60;x2&#62; &#60;y2&#62; &#60;z2&#62; [qs2 [occ2 [rad2]]] [1 1 1]<br/>
         ...   ...  ...<br/>
         &#60;atomN&#62; core &#60;xN&#62; &#60;yN&#62; &#60;zN&#62; [qN&nbsp;  [occN [0.0]]] [fixxN fixyN fixzN]<br/>
         &#60;atomN&#62; shel &#60;xN&#62; &#60;yN&#62; &#60;zN&#62; [qsN [occN [radN]]] [1 1 1]<br/>
         <br/>
         [velocities angs/ps]<br/>
         [...]<br/>
</code></p></div>

<p>As shown in this example, if an atom is made of a core and a shell, the coordinates of the shell appear right after the ones of the core.</p>

<p><strong>Values in square brackets</strong> will be written by Atomsk only if they are defined, either by being read from an input file or thanks to the <a href="./option_properties.html">option <code>-properties</code></a>.</p>

<p>So, if the electric charges of ions (q) are defined, they will be written. As stated in the GULP documentation, if electric charges are written, then the site occupancies (occ) may also be written (if they are defined). Similarly, if charges and occupancies are defined, then the radius for breathing shells (rad) may also be written. Note that the number of columns is always the same for cores and shells. A pair of core and shell will be given the same occupancy, and the breathing shell radius will be assigned only to the shell (for cores this column will contain 0.0).</p>

<p>The three flags ("<code>fixx fixy fixz</code>") at the end of each line mean that atoms will be free to move (1) or fixed (0) in the three directions of space. These flags will be written only if they are defined (e.g. if the <a href="./option_fix.html">option <code>-fix</code></a> is used). Shells will never be fixed and therefore will always have the flags "<code>1 1 1</code>". The six flags "<code>1 1 1 1 1 1</code>" after the supercell parameters are written only if some atoms are fixed, and indicate that the three cell dimensions <code>a,b,c</code> and the three angles <code>&alpha;,&beta;,&gamma;</code> will be optimized. Replace them by 0 to fix one or all of these parameters. Beware that these flags can have a different use when specific keywords are used in the header (like <code>conv</code> or <code>conp</code>), refer to the GULP manual for more information.</p>

<p>If velocities are defined, then they are written in a separate section after all atom positions.</p>

<p>All these properties are fully transferable when converting a GULP file to another GULP file. Note however that only atoms and their properties are transferred, not other sections of the file (like interatomic potential, etc.).</p>

<p>By default coordinates are written in the cartesian basis, but output to fractional coordinates can be triggered by the <a href="./option_fractional.html">option <code>-frac</code></a>.</p>

<p>Note that the GIN file that Atomsk writes is just a draft, it is NOT fully set for a simulation. It is up to the user to complete this GIN file with the simulation parameters (keywords, atomic potential, options for relaxation/MD, etc.) before running a simulation.</p>



<h4>Examples</h4>

<ul>
<li><code class="command">atomsk my_system.xsf -frac gin</code>
<p>This will read the file <code>my_system.xsf</code>, convert atom positions to <a href="./option_fractional.html">fractional coordinates</a>, and write the final result to <code>my_system.gin</code>.</p></li>

<li><code class="command">atomsk relaxed.grs -sort species pack xsf</code>
<p>This will read the GULP restart file <code>relaxed.grs</code>, <a href="./option_sort.html">sort atoms</a> according to their species, and write the final result to <code>relaxed.xsf</code>.</p></li>
</ul>

<p><a href="./index.html">Back to main menu</a></p>

</body>

</html>
